Technotes

Download Acrobat file (24K)

Download AppleWorks file (48K)

One of the constants in writing software for the Macintosh is that sooner or later your application will run out of available memory. While applications running on other operating systems may use memory allocated from a global pool (backed by virtual memory), and can thus draw on an apparently limitless supply, each Mac application must work to avoid exhausting the fixed amount of memory the Process Manager gave it. Since Toolbox calls share the same heap with application calls, and parts of the Toolbox are notoriously poor at dealing with failed allocations, it's essential that you put into place a robust strategy to manage the problem. Applications that fail under low-memory conditions are not very friendly.

This Technote expands on the chapter "Introduction to Memory Management" in Inside Macintosh:Memory. You should read at least pages 1-37 through 1-49 as a background to this Technote. Also, information on 68K segmentation assumes that you've read chapter 7 of Inside Macintosh:Processes.

Contents

• Maintaining a Memory Reserve
  
• Checking for Memory Allocations
  
• Informing the User of Low-Memory Conditions
  
• Using Temporary Memory
  
• Dealing With 68K Code Segments
  
• Special Problems with malloc and new
  
• Summary
  

Using A Purgeable Cushion

To create the memory reserve, allocate a handle early in your app's startup code. This handle should be in the range of 32K to 64K bytes in size, and should be marked as purgeable. When the Memory Manager later needs to create more free space, it will automatically purge any purgeable handles or resources.

During the main event loop, the application can check to see if the handle has been purged (if its master pointer is zero, it's been purged), and attempt to reallocate it with ReallocateHandle back to the original size. If this fails, then there is less than that amount of contiguous memory remaining, and the application can set a global flag to indicate that there is not enough memory to continue running as usual. It could then respond by warning the user to close documents, disabling menus that lead to memory-hungry functionality or in general keeping the user from pushing the limits of memory. When the handle can be reallocated again, the application can clear the global flag and reverse the steps it took earlier.

A useful technique is to only clear the global flag if you can recover the original memory plus an extra amount, as illustrated in the following code snippet:

extern Handle gReserveHandle; 
if (*gReserveHandle == nil) 		
	{
	ReallocateHandle(gReserveHandle, kReserveSize + kSlopFactor);
	if (MemError()!= noErr) 
		{
		SetHandleSize(gReserveHandle, kReserveSize);
		HPurge(gReserveHandle);
		SetReserveWasRecoveredFlag();
		}
	}

How large to make the handle depends on your application's needs. If large Toolbox data structures, such as GWorlds or pictures, can routinely consume all available memory, then a size larger than 64K may be necessary. The only way to know is to experiment with different sizes and test your application's features near the limits of memory. If it dies, increase the reserve size; if it survives gracefully, you may try to lower the size.

Installing A Grow Zone Procedure

Grow Zone Proc Strategies

The grow zone procedure can also undertake more complex and intelligent strategies to make memory available than the simple cushion techniques. The application may use buffers that can be shrunk or eliminated, or free up data structures stored in handles or pointers, or even mark additional resources as purgeable. It can also reduce its memory requirements in a gradual manner. Because the application may have knowledge of what blocks of memory and resources represent, it can free, shrink, or mark purgeable buffers to make memory available that cannot be made available automatically by the Memory Manager.

If the grow zone procedure returns with an indication that some memory was freed, the Memory Manager will again attempt another cycle of purging and compaction. It will continue calling the Grow Zone proc and purging and compacting until either memory becomes available or the Grow Zone proc returns zero. In the latter case, the Memory Manager will give up and return `memFullErr' to the code which attempted the allocation.

During the main event loop, attempts should be made to recover the memory. As the reserve is used and then recovered, a global variable or state could keep track of what level of reserves remain, and make this information available to the rest of the application.

A List of Safe Memory Manager Calls

• SetHandleSize, but only to a smaller size
• SetPtrSize, but only to a smaller size
• DisposeHandle
• DisposePtr
• EmptyHandle
• HPurge or the equivalent HSetState
• HUnlock or the equivalent HSetState

GZSaveHnd

What A Grow Zone Procedure Should Not Do

Examples of Things to Avoid in Grow Zone Procedures

Don't allocate memory

Don't do synchronous file I/O

Don't update resources

Don't put up dialogs

On 68K Macintoshes, don't call any routine that may force a segment to be loaded

Checking for Memory Allocations

You can avoid checking some allocations for failure, as long as you can be certain your memory state indicates the reserve or cushion will supply whatever memory is needed. You should avoid making potentially time-consuming calls such as PurgeSpace to determine if enough memory is available. This type of call could be saved until you need to check a memory requirement larger than could be supplied by the reserve or cushion.

Informing the User of Low-Memory Conditions

Developing a Two-Stage Plan

1. A warning that memory is becoming low (which could be shown when the memory reserve is shrunk, then reallocated)

2. A more serious indication that there is no memory remaining (when the memory reserve cannot be recovered)

Important:

Since memory alerts appear when there isn't very much memory left to work with, the resources and code needed to display them should be resident in memory. Many applications collect alert strings into a single STR# resource. If the Out of Memory message is in such a large resource, it may not be possible to load the resource to extract the individual string. It's better to keep these alerts resident in memory as much as possible with the string as a static item in the alert.

Guaranteeing the User Can Save Documents

You may also want to inform the user when a low memory crisis has been averted, i.e., now the user can relax because she's closed the necessary documents.

Note:

Applications that show memory availability in their About box should ensure that opening the About box when memory is very low does not exhaust what little memory remains.

When you allocate memory in the temporary heap (actually the Process Manager heap), you may make it difficult for the user to launch additional applications, since the applications will be launched into this heap. Your application also can't count on having any temporary memory available, so alternative strategies must always be designed for dealing with its absence.

Dealing With 68K Code Segments

Here are a few good strategies for dealing with 68K code segments.

A Few Good Strategies

The goal is to minimize the number of segments (and memory) needed for each operation or feature in the application. To accomplish this, you need to understand which parts of your app get called for each operation. A utility program such as Metrowerks' ZoneRanger can let you watch where the memory segments reside as your application executes.

Use a Single Segment

This may be ideal if your application is small, or memory requirements are not an issue -- e.g., for some vertical applications. Also, there's another important issue with regard to single-segment applications. If the application is going to be used on a PowerBook computer, then having a single segment is very desirable -- multiple segments will keep the hard disk spinning and decrease battery life.

Unload Segments in the Event Loop

1. Create a special routine in each segment with the name of the segment, and use that routine address in UnloadSeg. The segment contents can then be shifted around, without the need to search for a new routine to use, or worry if you've missed something.

2. Get the address directly by scanning the jump table for the first routine in each segment. This is highly dependent on the jump table format produced by your development environment. See the MacApp source file "USegments.cp" for an example.

Unload Segments at Any Time

The way to determine this at runtime is to scan the stack for any addresses contained within loaded segments. The steps to take each time are:

1. Construct a table with entries for each segment, containing the current memory location and size for each segment in memory, and a `keep' flag. Mark all resident segments' flag with true; mark all others as false.

2. Starting at the current value of register A7, scan to the address returned by LMGetCurStackBase, skipping two bytes at a time. Consider each value as a pointer. If this value is contained within the application heap zone, check to see if it is contained within a segment (using the table you constructed in Step #1). If it is, set the keep flag to true for that segment. Here you are basically looking for return addresses put on the stack during subroutine calls, which would indicate code in the call chain.

3. (using the technique of your choice to obtain an address from the segment).

Patch LoadSeg

For cases in which a segment cannot be loaded, you might want to throw a (C++) exception.

Special Problems with malloc and new

All C/C++ development environments provide versions of malloc and new which sub-allocate out of Memory Manager blocks created with NewPtr. These blocks are non-relocatable, and thus can severely fragment the heap, especially when memory is becoming scarce.

An additional problem is that some of these implementations of new and malloc fail to release these NewPtr blocks when they no longer contain any sub-allocated information. As these blocks begin to fill up the heap, there is less and less space available for Toolbox items such as windows, menus, or resources. It is important to limit the growth of these blocks to keep sufficient room available for Memory Manager allocations.

Some implementations of malloc and new allow you some control over their behavior; check your compiler's documentation for details. There are also commercially available alternative allocators, such as Smartheap, which may be of some help in dealing with this problem. Another possible solution is to create alternative heap zones within the application zone and keep all non-Memory Manager allocations within them.

Summary

• Inside Macintosh: Memory
• Inside Macintosh: Processes
• MacApp 3.3 on ETO #19